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Proxy Mobile IPv6 Extensions to Support Flow Mobility 
Abstract 


Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the 
same PMIPv6 domain through different interfaces. This document 
describes extensions to the PMIPv6 protocol that are required to 
support network-based flow mobility over multiple physical 
interfaces. 


This document updates RFC 5213. The extensions described in this 
document consist of the operations performed by the local mobility 
anchor and the mobile access gateway to manage the prefixes assigned 
to the different interfaces of the mobile node, as well as how the 
forwarding policies are handled by the network to ensure consistent 
flow mobility management. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7864. 
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1. Introduction 


Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network- 
based mobility management to hosts connecting to a PMIPv6é domain. 
PMIPv6 introduces two new functional entities, the Local Mobility 
Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the 
entity detecting the Mobile Node’s (MN’s) attachment and providing IP 
connectivity. The LMA is the entity assigning one or more Home 
Network Prefixes (HNPs) to the MN and is the topological anchor for 
all traffic belonging to the MN. 


PMIPv6 allows an MN to connect to the same PMIPv6 domain through 
different interfaces. This document specifies protocol extensions to 
Proxy Mobile IPv6 between the LMA and MAGs to enable "flow mobility" 
and, hence, distribute specific traffic flows on different physical 
interfaces. It is assumed that the MN IP-layer interface can 
simultaneously and/or sequentially attach to multiple MAGs, possibly 
over multiple media. One form to achieve this multiple attachment is 
described in [RFC7847], which allows the MN supporting traffic flows 
on different physical interfaces, regardless of the assigned prefixes 
on those physical interfaces. Another alternative is to configure 
the IP stack of the MN to behave according to the Weak ES Model 
(commonly referred to as the weak host model) [RFC1122]. 


In particular, this document specifies how to enable "flow mobility" 


in the PMIPv6 network (i.e., LMAs and MAGs). In order to do so, two 
main operations are required: i) proper prefix management by the 
PMIPv6 network and ii) consistent flow forwarding policies. This 


memo analyzes different potential use case scenarios, involving 
different prefix assignment requirements and, therefore, different 
PMIPv6 network extensions to enable "flow mobility". 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


The following terms used in this document are defined in the Proxy 
Mobile IPv6 [RFC5213]: 


o Local Mobility Anchor (LMA) 
o Mobile Access Gateway (MAG) 


o Proxy Mobile IPv6 Domain (PMIPv6—Domain) 
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o LMA Address (LMAA) 

o Proxy Care-of Address (Proxy-CoA) 

o Home Network Prefix (HNP) 

The following terms used in this document are defined in the Multiple 

Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile 

IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: 

o Binding Identification (BID) Number 

o Flow Identifier (FID) 

o Traffic Selector (TS) 

The following terms are defined and used in this document: 

o Flow Mobility Initiate (FMI): Message sent by the LMA to the MAG 
conveying the information required to enable flow mobility ina 


PMIPv6—-Domain. 


o Flow Mobility Acknowledgement (FMA): Message sent by the MAG in 
reply to an FMI message. 


o Flow Mobility Cache (FMC): Conceptual data structure to support 
the flow mobility management operations described in this 
document. 


3. Overview of the PMIPv6 Flow Mobility Extensions 
3.1. Use Case Scenarios 


In contrast to a typical handover where connectivity to a physical 
medium is relinquished and then re-established, flow mobility assumes 
that an MN can have simultaneous access to more than one network. In 
this specification, it is assumed that the LMA is aware of the MN’s 
ability to have simultaneous access to both access networks and the 
ability to handle the same or a different set of prefixes on each 
access. How this is done is outside the scope of this specification. 


There are different flow mobility scenarios. In some of them, the MN 
might share a common set of prefixes among all its physical 
interfaces; in others, the MN might have a different subset of 
prefixes configured on each of the physical interfaces. The 
different scenarios are the following: 
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1. At the time of a new network attachment, the MN obtains the same 
prefix or the same set of prefixes as already assigned to an 
existing session. This is not the default behavior with basic 
PMIPv6 [RFC5213], and the LMA needs to be able to provide the 
same assignment even for the simultaneous attachment (as opposed 
to the handover scenario only). 


2. At the time of a new network attachment, the MN obtains a new 
prefix or a new set of prefixes for the new session. This is the 
default behavior with basic PMIPv6 [RFC5213]. 


A combination of the two above-mentioned scenarios is also possible. 
At the time of a new network attachment, the MN obtains a combination 
of prefix(es) in use and new prefix(es). This is a hybrid of the two 
scenarios described before. The local policy determines whether the 
new prefix is exclusive to the new attachment or can be assigned to 
an existing attachment as well. 


The operational description of how to enable flow mobility in each of 
these scenarios is provided in Sections 3.2.1 and 3.2.2. 


The extensions described in this document support all the 
aforementioned scenarios. 


3.2. Basic Operation 


This section describes how the PMIPv6 extensions described in this 
document enable flow mobility support. 


Both the MN and the LMA MUST have local policies in place to ensure 
that packets are forwarded coherently for unidirectional and 
bidirectional communications. The details about how this consistency 
is ensured are out of the scope of this document. Either the MN or 
the LMA can initiate IP flow mobility. If the MN makes the flow 
mobility decision, then the LMA follows that decision and updates its 
forwarding state accordingly. The network can also trigger mobility 
on the MN side via out-of-band mechanisms (e.g., 3GPP / Access 
Network Discovery and Selection Function (ANDSF) sends updated 
routing policies to the MN). In a given scenario and MN, the 
decision on IP flow mobility MUST be taken either by the MN or the 
LMA, but it MUST NOT be taken by both. 
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3.2.1. MN Sharing a Common Set of Prefixes on All MAGs 


This scenario corresponds to the first use case scenario described in 
Section 3.1. Extensions to basic PMIPv6 [RFC5213] signaling at the 
time of a new attachment are needed to ensure that the same prefix 
(or set of prefixes) is assigned to all the interfaces of the same MN 
that are simultaneously attached. Subsequently, no further signaling 
is necessary between the local mobility anchor and the MAG, and flows 
are forwarded according to policy rules on the LMA and the MN. 


If the LMA assigns a common prefix (or set of prefixes) to the 
different physical interfaces attached to the domain, then every MAG 
already has all the routing knowledge required to forward uplink or 
downlink packets after the Proxy Binding Update / Proxy Binding 
Acknowledgement (PBU/PBA) registration for each MAG, and the LMA does 
not need to send any kind of signaling in order to move flows across 
the different physical interfaces (because moving flows is a local 
decision of the LMA). Optionally, signaling MAY be exchanged in case 
the MAG needs to know about flow-level information (e.g., to link 
flows with proper QoS paths and/or inform the MN [RFC7222]). 


The LMA needs to know when to assign the same set of prefixes to all 
the different physical interfaces of the MN. This can be achieved by 
different means, such as policy configuration, default policies, etc. 
In this document, a new Handoff Indicator (HI) ("Attachment over a 
new interface sharing prefixes" (6) value) is defined that allows the 
MAG to indicate to the LMA that the same set of prefixes MUST be 
assigned to the MN. The considerations of Section 5.4.1 of [RFC5213] 
are updated by this specification as follows: 


o If there is at least one Home Network Prefix Option present in the 
request with a NON_ZERO prefix value, there exists a Binding Cache 
Entry (BCE) (with all HNPs in the BCE matching the prefix values 
of all Home Network Prefix Options of the received Proxy Binding 
Update message), and the entry matches the MN identifier in the 
Mobile Node Identifier Option of the received Proxy Binding Update 
message, and the value of the HI of the received Proxy Binding 
Update is equal to "Attachment over a new interface sharing 
prefixes". 


1. If there is a Mobile Node Link-layer Identifier Option present 
in the request, and the BCE matches the Access Technology Type 
(ATT) and the MN-LL-Identifier, then the request MUST be 
considered as a request for updating that BCE. 
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If there is a Mobile Node Link-layer Identifier Option present 
in the request, and the BCE does not match the Access 
Technology Type (ATT) and the MN-LL-Identifier, then the 
request MUST be considered as a request for creating a new 
mobility session sharing the same set of HNPs assigned to the 
existing BCE found. 


If there is not a Mobile Node Link-layer Identifier Option 
present in the request, then the request MUST be considered as 
a request for creating a new mobility session sharing the same 
set of HNPs assigned to the existing BCE found. 


LMA Binding Cache 


+---+ 
| LMA | MN1, ATT1, prefl, MAG1 
+---+ MN1, ATT2, prefl, MAG2 
//\\ 
+--------- [JAS AS + 
( // \\ ) PMIPv6 domain 
( // \\ ) 
+------ //[-------- \\esSss5-=-= + 
// A 
// \\ 
+----+ +----+ 
|MAG1 | | MAG2 | 
+----+ +----+ 
| | 
+------- + 
ee || 
+---+---+ 
|---|if1|i£2|----| 
+---+---+ 
MN1 


Figure 1: Shared Prefix Across Physical Interfaces Scenario 


Next, 


an example of how flow mobility works in this case is shown. 


In Figure 1, a mobile node (MN1) has two different physical 
interfaces (ifl of access technology type ATT1, and if2 of access 
technology type ATT2). Each physical interface is attached to a 
different MAG, both of them controlled by the same LMA. Both 
physical interfaces are assigned the same prefix (prefl) upon 
attachment to the MAGs. If the IP layer at the MN shows one single 
logical interface (e.g., as described in [RFC7847]), then the mobile 
node has one single IPv6 address configured at the IP layer: 


prefl: 
prefl: 


:mnl. Otherwise, per interface IPv6 addresses (e.g., 
:ifl and prefl::if2) would be configured; each address MUST be 


valid on every interface. We assume the first case in the following 


Bernardos 
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example (and in the rest of this document). Initially, flow X goes 
through MAG1 and flow Y through MAG2. At a certain point, flow Y can 
be moved to also go through MAG1. Figure 2 shows the scenario in 


which no flow-level information needs to be exchanged, so there is no 
signaling between the LMA and the MAGs. 


Note that if different IPv6 addresses are configured at the IP layer, 
IP-session continuity is still possible (for each of the configured 
IP addresses). This is achieved by the network delivering packets 
destined to a particular IP address of the MN to the right of MN’s 
physical interface where the flow is selected to be moved, and the MN 
also selecting the same interface when sending traffic back uplink. 


4+----- + 4+------ + 4+------ + 4+----- + 
Internet | LMA | | macı | | MAG2 | | MN1 | 
4+----- + 4+------ + +------ + 4+----- + 

| | | | | 
| flow X to | flow X to | flow X to 
| pref1::mn1 | pref1::mn1 | pref1::mn1 
|<----------- > | <------------- > | <-------------------------- >ifl 
| flow Y to | flow Y to | flow Y to | 

pref1::mn1 pref1::mn1 pref1::mn1 | 
<----------- > | <----------------------------- > | <---------- >1if2 
| | | | | 
| ============ | | ============ 
| || flow || | | || flow || 
| || policy || | | || policy || 
| || update | | | || update | | 
| | | | | 
| flow Y to | flow Y to | flow Y to 
| pref1::mn1 | pref1::mn1 | pref1::mn1 
|<----------- >|<------------- > | <-------------------------- >ifl 
| | | | 


Figure 2: Flow Mobility Message Sequence with a Common Set of 
Prefixes 


Figure 3 shows the state of the different network entities after 
moving flow Y in the previous example. This document reuses some of 
the terminology and mechanisms of the flow bindings and multiple 
care-of address registration specifications. Note that, in this case 
the BIDs shown in the figure are assigned locally by the LMA, since 
there is no signaling required in this scenario. In any case, 
alternative implementations of flow routing at the LMA MAY be used, 
as it does not impact the operation of the solution in this case. 
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LMA flowmob state 


(BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 
4+---+ 
|LMA| 1, MN1, ATT1, prefl, MAG1 1, flow X 
+---+ 2, MN1, ATT2, prefl, MAG2 1, flow Y 
//\\ 
Pesasssss= fil PAN NARS Sa Sa SS aaas + 
// \\ ) PMIPv6 domain 
// \\ ) 
| aera lt ee o + 
// \\ 
// \\ MAG1 routing state 
4+----+ 4+----+ 
| MAG]. | | MAG2 | (dest) (next hop) 
+----+ +----+ pref1::/64 p2p-iface-with-MN1 
3520/10 LMA 
| | MAG2 routing state 
—— + | 
| | IP | | (dest) (next hop) 
| +---+---+ | pref1::/64 p2p-iface-with-MN1 
|---|if1|i£f2|----| 21/0 LMA 
4+---+---+ 
MN1 
Figure 3: Data Structures with a Common Set of Prefixes 


Deas 


MN with Different Sets of Prefixes on Each MAG 

A different flow mobility scenario happens when the LMA assigns 
different sets of prefixes to physical interfaces of the same mobile 
node. This covers the second case, or a combination of scenarios, 
described in Section 3.1. In this case, additional signaling is 
required between the LMA and the MAG to enable relocating flows 
between the different attachments, so the MAGs are aware of the 
prefixes for which the MN is going to receive traffic, and local 
routing entries are configured accordingly. 


In this case, signaling is required when a flow is to be moved from 
its original interface to a new one. Since the LMA cannot send a PBA 
message that has not been triggered in response to a received PBU 
message, the solution defined in this specification makes use of two 
mobility messages: FMI and FMA, which actually use the format of the 
Update Notifications for PMIPv6é defined in [RFC7077]. The trigger 
for the flow movement can be on the MN (e.g., by using layer-2 
Signaling with the MAG), or on the network (e.g., based on congestion 
and measurements), which then notifies the MN for the final IP flow 
mobility decision (as stated in Section 3.1). Policy management 
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3GPP/ANDSF) 
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can be used for that purpose; 
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however, 


how the network notifies the MN is out of the scope of this document. 


If the flow is being moved from its default path 
by the destination prefix) 


FMI message. 


to a different one, 


(which is determined 
the LMA constructs a 
This message includes a Home Network Prefix Option for 


each of the prefixes that are requested to be provided with flow 


mobility support on 


anchored by the target MAG, 


them on the MAG-MN 


message MUST be sent to the new target MAG, 


be used in the forw 
The message sequenc 


the new MAG 


with the off-link bit 
esy 


link), 


arding of the flow. 
e is shown in Figure 4. 


(note that these prefixes are not 
and therefore the MAG MUST NOT advertise 
(L) 
the one selected to 
The MAG replies with an FMA. 


set to one. This 


-+ +------ + +------ + 4+----- + 
| | MAG1 | | MAG2 | | MN1 | 
-+ 4+------ + 4+------ + 4+----- + 
| | | 
flow X to | flow X to | 
pref1::mn1 | pref1::mn1 
------------- > | <-------------------------->ifl 
flow Y to | flow Y to 
pref2::mnl1 pref2::mn1 
—---------------------------- > | <---------->if2 
| | | 
==== | | ============ 
|] | | || flow || 
Yy policy 
e | | | | update | 
ss | | a 
| | | 
FMI[MN1-ID, HNPs] | | 
------------- >| | | 
Pa | | 
flow Y to | flow Y to 
pref2::mnl | pref2::mn1 
------------- > | <-------------------------->ifl 
| 


Flow Mobility Message Sequence When the LMA Assigns 


Different Sets of Prefixes per Physical Interface 


+---—- 
Internet | LMA 
+---—- 
| | 
| flow X to | 
| pref1::mn1 | 
|<----------- >|< 
flow Y to 
pref2::mn1 
|<----------- >|< 
| | 
| z=z2s324 
| | | flow 
polic 
updat 
| pope eee ee 
| | 
| | 
| be 
| : 
| flow Y to | 
| pref2::mn1 | 
|<----------- >|< 
| | 
Figure 4: 
Bernardos 
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The state in the network after moving a flow, in the case where the 
LMA assigns a different set of prefixes is shown in Figure 5. 


LMA Binding Cache LMA flowmob state 
(BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 
4+---+ 
|LMA| 1, MN1, ATT1, prefl, 1, flow X 
+---+ pref2, MAGI 1, flow Y 
//\\ 2, MNL, ATT2, pref2, MAG2 
5 a (f= \Nas oS se sasSseo + 
( // \\ ) PMIPv6 domain 
( // \\ ) 
TSRS lt ae AE a + 
// \\ 
// \\ MAG1 routing state 
4+----+ 4+----+ 
| MAG]. | | MAG2 | (dest) (next hop) 
+----+ +----+ pref1::/64 p2p-iface-with-MN1 
| | pref2::/64 p2p-iface-with-MN1 
| | ::/0 LMA 
+------- + MAG2 routing state 
ko aes 
| +---+---+ | (dest) (next hop) 
|---|if1|i£2|----| pref2::/64 p2p-iface-with-MN1 
+---+---+ 22/0 LMA 
MN1 


Figure 5: Data Structures When the LMA Assigns a Different Set of 
Prefixes 


3.3. Use of PBU/PBA Signaling 


This specification introduces the FMI/FMA signaling, which allows the 
LMA to exchange required information with the MAG to enable flow 
mobility without waiting to receive a PBU. However, there are 
scenarios in which the trigger for flow mobility might be related to 
a new MN’s interface attachment. In this case, the PBA sent in 
response to the PBU received from the new MAG can convey the same 
Signaling that the FMI does. In this case, the LMA MUST include a 
Home Network Prefix Option in the PBA for each of the prefixes that 
are requested to be provided with flow mobility support on the new 
MAG with the off-link bit (L) set to one. 
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3.4. Use of Flow-Level Information 


This specification does not mandate flow-level information to be 
exchanged between the LMA and the MAG to provide flow mobility 
support. It only requires that the LMA keeps a flow-level state 
(Section 5.2). However, there are scenarios in which the MAG might 
need to know which flow(s) is/are coming within a prefix that has 
been moved, to link it/them to the proper QoS path(s) and optionally, 
inform the MN about it. This section describes the extensions used 
to include flow-level information in the signaling defined between 
the LMA and the MAG. 


This specification reuses some of the mobility extensions and message 
formats defined in [RFC5648] and [RFC6089], namely the Flow 
Identification Mobility Option and the Flow Mobility Sub-Options. 


If the LMA wants to convey flow-level information to the MAG, it MUST 
include in the FMI (or the PBA) a Flow Identification Mobility Option 
for all the flows that the MAG needs to be aware of with flow 
granularity. Each Flow Identification Mobility Option MUST include a 
Traffic Selector Sub-Option including such flow-level information. 


To remove a flow-binding state at the MAG, the LMA simply sends an 
FMI (or a PBA, if it is in response to a PBU) message that includes 
flow identification options for all the flows that need to be 
refreshed, modified, or added, and simply omits those that need to be 
removed. 


Note that even if a common set of prefixes is used, providing the MAG 
with flow-level information requires signaling to be exchanged, in 
this case between the LMA and the MAG. This is done by sending an 
FMI message (or a PBA, if it is sent in response to a PBU). 


4. Message Formats 


This section defines modifications to the PMIPv6 [RFC5213] protocol 
messages. 


This specification requires implementation of Update Notification 
(UPN) [RFC7077] and Update Notification Ack (UPA) [RFC7077] messages 
with the specific Notification Reason and Status Code values as 
defined by this document. This document does not require 
implementation of any other aspects of [RFC7077]. 
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4.1. Home Network Prefix 


A new flag (L) is included in the Home Network Prefix Option to 
indicate to the MAG whether the conveyed prefix has to be hosted on- 
link or not on the point-to-point interface with the MN. A prefix is 
hosted off-link for the flow mobility purposes defined in this 
document. The rest of the Home Network Prefix Option format remains 
the same as defined in [RFC5213]. 


0 1 2 3 
OD 2.3456 7 -8° 9° 0-1 2-3 4.556 78 Gyo 1, -2.:3.4-5. 6 7 8 9. OT 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length |L] Reserved | Prefix Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| | 
+ + 
| | 
+ Home Network Prefix + 
| | 
+ + 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Off-link Home Network Prefix Flag (L): 


The Off-link Home Network Prefix Flag is set to indicate to the 
MAG that the HNP conveyed in the option is not to be hosted on- 
link, but has to be considered for flow mobility purposes, and 
therefore added to the MAG routing table. If the flag is set to 
0, the MAG assumes that the HNP has to be hosted on-link. 


4.2. Flow Mobility Initiate (FMI) 


The FMI message used in this specification is the UPN message 
specified in [RFC7077]. The message format, transport, and security 
considerations are as specified in [RFC7077]. The format of the 
message is specified in Section 4.1 of [RFC7077]. This specification 
does not modify the UPN message; however, it defines the following 
new notification reason value for use in this specification: 


Notification Reason: 
FLOW-MOBILITY (8). Request to add/refresh the prefix(es) conveyed 


in the Home Network Prefix Options included in the message to the 
set of prefixes for which flow mobility is provided. 
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The Mobility Options field of an FMI MUST contain the MN-ID, followed 
by one or more Home Network Prefix Options. Prefixes for which flow 
mobility was provided that are not present in the message MUST be 
removed from the set of flow mobility-enabled prefixes. 


4.3. Flow Mobility Acknowledgement (FMA) 


The FMA message used in this specification is the UPA message 
specified in Section 4.2 of [RFC7077]. The message format, 
transport, and security considerations are as specified in [RFC7077]. 
The format of the message is specified in Section 4.2 of [RFC7077]. 
This specification does not modify the UPA message, however, it 
defines the following new status code values for use in this 
specification: 


Status Code: 
0: Success 
131: Reason unspecified 
132: MN not attached 


When the Status code is 0, the Mobility Options field of an FMA MUST 
contain the MN-ID, followed by one or more Home Network Prefix 
Options. 


5. Conceptual Data Structures 


This section summarizes the extensions to PMIPv6é that are necessary 
to manage flow mobility. 


5.1. Multiple Proxy Care-of Address Registration 


The binding cache structure of the LMA is extended to allow multiple 
proxy care-of address (Proxy-CoA) registrations, and support the 
mobile node using the same address (prefix) beyond a single interface 
and MAG. The LMA maintains multiple BCEs for an MN. The number of 
BCEs for an MN is equal to the number of the MN’s interfaces attached 
to any MAGs. 


This specification reuses the extensions defined in [RFC5648] to 
manage multiple registrations, but in the context of PMIPv6. The 
binding cache is therefore extended to include more than one proxy 
care-of address and to associate each of them with a BID. Note that 
the BID is a local identifier, assigned and used by the local 
mobility anchor to identify which entry of the FMC is used to decide 
how to route a given flow. 
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4+--------- +----- 4+------- 4+------ 4+----------- 4+------------ + 
| BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | 
4+--------- +----- 4+------- 4+------ 4+----------- 4+------------ + 
| 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | 
| 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | 
4+--------- +----- 4+------- 4+------ 4+----------- 4+------------ + 


Figure 6: Extended Binding Cache 

Figure 6 shows an example of an extended binding cache, containing 
two BCEs of a mobile node MN1 attached to the network using two 
different access technologies. Both of the attachments share the 
same prefix (HNP1), but they are bound to two different Proxy-CoAs 
(two MAGs). 

5.2. Flow Mobility Cache (FMC) 
Each LMA MUST maintain an FMC as shown in Figure 7. The FMC is a 
conceptual list of entries that is separate from the binding cache. 
This conceptual list contains an entry for each of the registered 
flows. This specification reuses the format of the flow-binding list 
defined in [RFC6089]. Each entry includes the following fields: 
o Flow Identifier Priority (FID-PRI) 
o Flow Identifier (FID) 
o Traffic Selector (TS) 
o Binding Identification (BID) 


o Action 


o Active/Inactive 


4+--------- 4+----- 4+----- 4+------ 4+--------- 4+---------- + 
| FID-PRI | FID | TS | BIDs | Action | A/I | 
4+--------- 4+----- 4+----- 4+------ 4+--------- 4+---------- + 
| 10 | 2 ees | 1 | Forward | Active | 
| 20 | 4 | UDP | 172 | Forward | Inactive | 
4+--------- 4+----- 4+----- 4+------ 4+--------- 4+---------- + 


Figure 7: Flow Mobility Cache 


The BID field contains the identifier of the BCE to which the packets 
matching the flow information described in the TS field will be 
forwarded. When it is decided that a flow is to be moved, the 
affected BID(s) of the table are updated. 
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Similar to the flow binding described in [RFC6089], each entry of the 
FMC points to a specific BID. When a flow is moved, the LMA simply 
updates the pointer of the flow-binding entry with the BID of the 
interface to which the flow will be moved. The TS in the flow- 
binding table is defined in [RFC6088]. TS is used to classify the 
packets of flows based on specific parameters such as service type, 
source, and destination address, etc. The packets matching with the 
same TS will be applied the same forwarding policy. FID-PRI is the 
order of precedence to take action on the traffic. The action may be 
to forward or drop. If a binding entry becomes "Inactive", it does 
not affect data traffic. An entry becomes "Inactive" only if all of 
the BIDs are de-registered. 


The MAG MAY also maintain a similar data structure. In case no full 
flow mobility state is required at the MAG, the Binding Update List 
(BUL) data structure is enough: no extra conceptual data entries are 
needed. If full per-flow state is required at the MAG, it SHOULD 
also maintain an FMC structure. 


6. Mobile Node Considerations 


This specification assumes that the mobile node IP-layer interface 
can simultaneously and/or sequentially attach to multiple MAGs, 
possibly over multiple media. The MN MUST be able to enforce uplink 
policies to select the right outgoing interface. One alternative to 
achieve this multiple attachment is described in [RFC7847], which 
allows the MN supporting traffic flows on different physical 
interfaces, regardless of the assigned prefixes on those physical 
interfaces. Another alternative is configuring the IP stack of the 
MN to behave according to the weak host model [RFC1122]. 


7. IANA Considerations 


This specification establishes new assignments to the IANA mobility 
parameters registry: 


o Handoff Indicator Option type: "Attachment over a new interface 
sharing prefixes" has been assigned the value 6 from the "Handoff 
Indicator Option type values" registry defined in 
<http://www.iana.org/assignments/mobility-parameters>. 


o Update Notification Reason: "FLOW-MOBILITY" has been assigned the 
value 8 from the "Update Notification Reasons Registry" defined in 
<http://www.iana.org/assignments/mobility-parameters>. 
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o Update Notification Acknowledgement Status: "Reason unspecified" 
has been assigned the value 131 and "MN not attached" has been 
assigned the value 132 from the "Update Notification 
Acknowledgement Status Registry". 


8. Security Considerations 


The protocol-signaling extensions defined in this document share the 
same security concerns of Proxy Mobile IPv6 [RFC5213] and do not pose 
any additional security threats to those already identified in 
[RFC5213] and [RFC7077]. 


The MAG and the LMA MUST use the IPsec security mechanism mandated by 
Proxy Mobile IPv6é [RFC5213] to secure the signaling described in this 
document. 
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